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Description 

Background of the Invention 

[0001] The present invention relates to electronic data 
processing, and more specifically concerns new query 
operations for the manipulation of tables in relational 
databases . 

[0002] A database is a collection of data in an organ- 
ized structure. A typical database is stored in a computer 
as a set of records each having a number of fields for 
holding data items of a particular kind, such as character 
strings, numbers, or pointers to data located some- 
where else. A relational database comprises any 
number of rectangular tables. Each table has a set of 
records; each record is referred to as a row of its table. 
Each record in the same table has the same number of 
fields. (However, some fields in a record may hold no 
data, indicated by a NULL value.) The fields of a table 
form a set of columns, which may have designated 
names that are not part of the data itself. The records 
do not have external to identify them individually. In- 
stead, they are accessed by a key consisting of the con- 
tents of some combination of the fields; that is, a rela- 
tional database may be considered to be a software-im- 
plemented content-addressable memory. 
[0003] A database management system (DBMS, or 
database system) is computer software for storing, 
maintaining, and searching the data in a database. A 
DBMS usually includes facilities for increasing perform- 
ance, reliability, and integrity, such as indexes, logging, 
and record locking. It always includes one or more in- 
terfaces for finding particular data from the database 
and for presenting these queries to a search engine. The 
engine searches the database and returns to the user 
a result, usually in the form of a relational table, which 
matches the specifications of the query. 
[0004] The most widespread interface for relational 
databases is Structured Query Language (SQL). Al- 
though many variants of this interface language exist, 
standard versions have been defined by the American 
National Standards Institute (ANSI) and the Internation- 
al Standards Organization (ISO). Most present commer- 
cial realizations of SQL follow these standard versions, 
although many of them include language constructs in 
addition to those defined in the standard, or at different 
levels of compliance. 

[0005] Relational databases and relational query lan- 
guages treat data as a set of rectangular tables. Yet 
many databases are conceptually multidimensional, 
based upon axes such as time {day, month, year}, locale 
{store, city, state}, category {product, p rod uct_g roup}, 
actor {clerk, department, division}, payment {cash, 
check, credit}, and so forth. A user often finds it useful 
to think of such data as a collection of collections, and 
may wish to view them from different perspectives. In 
the above example, one perspective is a collection of 
records, where each record represents a locale, and 



contains a collection of monthly sales data for that lo- 
cale; another perspective sees a collection of records (i. 
e., rows of a table) where each denotes a particular point 
in time, and the fields of each record (i.e., the columns 
5 of the table) collect sales figures for the different cate- 
gories. 

[0006] From this point of view, the ability to transform 
a database table from one perspective to another — to 
rotate the dimensions of the data — would be a valuable 
addition to the conventional capabilities of a query lan- 
guage such as SQL. In this context, to rotate perspec- 
tives or dimensions means to interchange a dimension 
represented in a table as a set of columns with a dimen- 
sion represented as a set of rows. Conventional rela- 
tional DBMS products and standards offer no direct op- 
eration for rotating perspectives. Although it is possible 
to formulate SQL queries to achieve this effect indirectly, 
such queries are large, complex, error-prone, slow, and 
hard to optimize into efficient execution plans, even 
when parallel processing is available. 
[0007] Some conventional spreadsheet software al- 
lows a user to interchange data in a user-selected rec- 
tangle of cells to be interchanged in the same way that 
a matrix-algebra "transpose" operation relocates a ma- 
trix element a^to a y7 . In the Microsoft Excel product's Piv- 
ot Table feature, for example, a user selects a rectangle 
of cells, copies it into a temporary clipboard, points to a 
destination cell, and performs a "paste special" opera- 
tion after selecting "transpose" from an options menu. 
With a suite of compatible application programs such as 
Microsoft Office, a user may even select data from a da- 
tabase table in the Microsoft Access database compo- 
nent, transfer it as a single object to the Excel compo- 
nent as a rectangle of spreadsheet cells, transpose the 
cells, then transfer the cells back into the Access data- 
base as a collection of records in the transposed format. 
Pivot operations in spreadsheets are described in J. C. 
Nossiter, USING EXCEL 5 FOR WINDOWS Que Corp, 

1995) and in B. Desmarais, "Using the Microsoft Excel 
Pivot Table for Reliability Applications", IEEE 34TH AN- 
NUAL SPRING RELIABILITY SYMPOSIUM (18 April 

1996) , pages 79-81. 

[0008] Transposing data items in this manner is both 
clumsy and functionally limited. Even for small databas- 
es, the invocation of another application program merely 
to carry out a single query is wasteful. For large data- 
bases, the conventional requirement that transposed 
data reside in memory renders this method impossible. 
For client/server architectures using host-based search 
engines, there is no way to connect to a spreadsheet 
program for performing the operation. In any environ- 
ment, transposition via spreadsheet requires manual in- 
tervention, and thus does not permit a transposition to 
form an internal part of a query within a database pro- 
gram. Such external operations cannot participate in the 
sophisticated reformulation, rewriting, and other optimi- 
zation procedures of conventional database-query 
processors and other search engines. On a more con- 
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ceptual level, fundamental differences between spread- 
sheets and relational database tables prohibit the de- 
sired types of transposition. For example, the names of 
the columns or fields in a database table are not a part 
of the table itself; they do not form a record of the table 
in the way that column headings in a spreadsheet are a 
row of cells within the spreadsheet. Transposing a rec- 
tangle of cells in a spreadsheet thus cannot transform 
a column of cells into the names of columns when the 
spreadsheet rows return to the database progrumas 
records in a table. 

[0009] Some non-relational database systems have 
operations similar to spreadsheet pivot operations. 
OLAP (on-line analytical processing) can perform a ro- 
tate operation upon multidimensional "cube" data, as 
noted in U. Flohr, "OLAP by Web", BYTE, September 
1997, pages 81-84, in E. Lindholm et al., "DATAMA- 
TION'S Feature Summary: OLAP Servers", DATAMA- 
TION, May 1985, pages 70-71, in M. Frank, "BrioQuery 
3.5", DBMS ONLINE, February 1996, in "OLAP and 
OLAP Server Definitions", (OLAP Council, 1995), and 
in C. B. Darling, "Think Outside the OLAP Box", DATA- 
MATION, 15 April 1996, pages 88-92. 
[0010] The execution engine of the Microsoft SQL 
Server product has a strictly internal operation for split- 
ting each item of a table update having the form 
(row_identifier, old_values, new_values) within a 
stream of update items into a "delete item" and an "insert 
item" which interchanges certain row and column val- 
ues, and a similar operation for collapsing a "delete 
item" and an "insert item" into an "update item". These 
operations are not available to users and cannot partic- 
ipate in user queries. That is, the query processor uses 
them internally only for facilitating the efficient execution 
of certain functions performed while updating databas- 
es. 

[0011] Thus, the database art could be significantly 
expanded by providing a facility for fast, efficient rotation 
of perspectives, especially for relational databases. 
Moreover, there is a need for rotation or transposition 
operations whose semantics and syntax integrate well 
into query languages such as SQL as natural exten- 
sions, and which can be optimized and executed in con- 
ventionally organized database query processors and 
other search engines without adding complex or idio- 
syncratic facilities. 

Summary of the Invention 

[0012] The present invention as defined in claims 1, 
11 and 17 provides a "pivot" operation for transforming 
the rows (records) and columns (fields) of a table, as 
that term is defined in a relational database, so as to 
provide different perspectives into the data items in the 
table. The operation accepts an input table and a pivot 
specification, and produces an output table. It takes 
place in the interface-language organization in such a 
way that it can be easily integrated into conventional da- 



tabase query processors, search engines, and servers. 
The operation places data in the fields of specified table 
records into the same field of different records, using the 
values of one or more designated table column as the 

5 names of the fields themselves. Data in any further col- 
umns are grouped by data values in a pivoted table. 
[0013] It is sometimes easier to perform other rela- 
tional operations upon a database table from another 
perspective, even when the ultimate result will have the 

10 original perspective. Therefore, the invention as defined 
in claims 7, 15 and 19 also provides an "unpivot" oper- 
ation as an inverse to the pivot facility. Also, sometimes 
it is desirable to unpivot a stored table or intermediate 
result. 

15 [0014] These operations, along with a simple and in- 
tuitive way of incorporating them into database queries, 
simplifies the writing of queries and makes them less 
error-prone. For example, they reduce or eliminate the 
need for joining tables to themselves. The method of in- 
20 voking the operations permits deep nesting of multiple 
operations with a simple and powerful syntax extension 
and well-defined semantics, and applies a familiar pro- 
gramming-language paradigm. Permitting text as meth- 
od arguments in queries enhances the power and ease 
25 of use of the extended SQL language. Moreover, ex- 
panding the set of relational-algebra expressions avail- 
able in this manner to nonprocedural query expressions 
may also be applied to other operations, such as sam- 
ple, top, and rank. 
30 [0015] Pivot and unpivot operations according to the 
invention are inherently compatible with many types of 
data-manipulation software, and system architectures, 
especially including relational databases. These opera- 
tions can be integrated into such systems both at the 
35 language level (e.g., by means of intuitive extensions to 
SQL and other query languages) and at the processing 
level (e.g., query optimization and execution). 
[0016] Integrating data from multiple databases into 
a single data-warehouse database frequently faces an 
40 "impedance mismatch" when the multiple data sources 
have mutually differing shapes or row/column ratios. Al- 
most by definition, such databases can be extremely 
large. Normalizing such data may depend upon context: 
storing data in pivoted form or perspective may be op- 
45 timal — or even necessary-for one schema, while anoth- 
er schema may prefer or require the unpivoted form. 
Therefore, adding pivot and unpivot operations can 
greatly benefit the combination of data from different 
sources, especially large amounts of data. 
50 [0017] The new operations provided by the invention 
also expedite lower-level DBMS processing, even with 
limited system resources. The extensible syntax and 
clear semantics of the new operations facilitates auto- 
matic generation and optimization of complex queries, 
55 especially in the rewriting of queries for more efficient 
execution. Even purely internal DBMS functions, such 
as update processing for index and integrity mainte- 
nance and other purposes, can benefit. The processing 
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of SQL queries involving IN, OR, and UNION queries 
can be enhanced. Many optimization techniques al- 
ready employed for GROUP BY queries are routinely 
adaptable to processing pivot and unpivot queries. Con- 
ventional execution algorithms including parallel- 5 
processing techniques for these queries apply to pivot- 
ing tables or query results, including unsorted and par- 
titioned tables and results. 

[0018] Other features and advantages of the inven- 
tion, as well as variations within the scope of the inven- 10 
tion, will appear to those skilled in the art from the fol- 
lowing detailed description. 

Brief Description of the Drawing 

15 

[0019] 

Fig. 1 is a block diagram of a computer network en- 
vironment for the invention. 

Fig. 2 is a diagram of a database management sys- 20 
tern for hosting the invention. 
Fig. 3 is a flowchart of the functions performed by 
the DBMS of Fig. 2. 

Fig. 4 illustrates examples of pivot and unpivot op- 
erations according to the invention. 25 
Fig. 5 is a flowchart of a pivot operation according 
to the invention. 

Fig. 6 is a flowchart of an unpivot operation. 

Detailed Description 30 

Exemplary Operating Environment 

[0020] Datanase management systems are imple- 
mented in many different types of data-processing sys- 35 
terns, including standalone personal computers, mid- 
range and mainframe computers, peer-to-peer and cli- 
ent/server networks, and wide-area distributed systems 
of many architectures. All data-processing systems are 
suitable environments for the present invention. For pur- 40 
poses of exposition, however, the invention will be de- 
scribed in connection with a conventional client/server 
computer system 100, shown in Fig. 1. Network wiring 
110 interconnects a number of personal computers 
(PCs) 1 20 to a server 1 30 via network adapters 1 21 and 45 
131 . Server 130 includes a storage subsystem 132 for 
holding the large amounts of data in typical enterprise 
databases. Other system architectures are also suitable 
environments for the invention; for example, units 120 
may be terminals connected to a mainframe or mid- 50 
range computer 130, or unit 130 may itself comprise a 
PC coupled to PCs 120 in a peer-to-peer network. For 
small and modest databases, the entire system 1 00 may 
comprise a single PC acting as both client and server. 
Likewise, file storage may be distributed among a 55 
number of different machines. Fig. 1 shows schematic 
representations of an external storage medium 133 
which may store client and server software for distribu- 



6 

tion and downloading to clients, and another medium 
134, such as a diskette, for offline storage of database 
tables. 

[0021] Figure 1 A and the following discussion are in- 
tended to provide a brief, general description of a per- 
sonal computer 120. Although not required, the inven- 
tion will be described in the general context of computer- 
executable instructions, such as program modules, be- 
ing executed by a personal computer. Generally, pro- 
gram modules include routines, programs, objects, 
components, data structures, etc. that perform particu- 
lar tasks or implement particular abstract data types. 
Moreover, those skilled in the art will appreciate that the 
invention may be practiced with other computer system 
configurations, including hand-held devices, multiproc- 
essor systems, microprocessor-based or programma- 
ble consumer electronics, network PCs, minicomputers, 
mainframe computes, and the like. The invention may 
also be practiced in distributed computing environments 
where tasks are performed by remote processing devic- 
es that are linked through a communications network. 
In a distributed computing environment, program mod- 
ules may be located in both local and remote memory 
storage devices. 

[0022] Fig. 2 is a block diagram of a typical conven- 
tional client/server database management system 200 
capable of operating in system 100, Fig. 2. A client ap- 
plication program 21 0 executes within each PC 1 20, un- 
der a PC operating system 220 such as Microsoft 
Windows95. Among other functions, client application 
210 contains a facility 211 for accepting database que- 
ries from a user at a PC 120. In addition to user entries, 
other application programs 230 executing in some of the 
PCs 120 may present queries to DBMS client 210, via 
predefined host-language application-program interfac- 
es (APIs) 231. 

[0023] Within server 130, a DBMS server application 
240, such as Microsoft SQL Server, executes under a 
server operating system 250 such as Microsoft Win- 
dows NT. DBMS program 240 provides services for cre- 
ating, querying, maintaining, and modifying a number of 
relational databases, exemplified by database 260. Pro- 
gram 240 may employ the file-system services 251 of 
operating system 250, or may provide its own file sys- 
tem. Operating system 250 could execute a separate 
instance of the entire DBMS application for each request 
from a client 210. For greater efficiency, however, pro- 
gram 240 gives each client connection a separate 
thread 242 in the DBMS kernel. Further, this thread may 
be a native operating-system thread, which carries with 
it all the Windows NT mechanisms for process memory 
protection, better access to storage devices, and so 
forth. Search engine 241 processes queries and other 
requests from individual clients 210 upon tables 261 of 
a database 260, as described more fully below. It also 
enforces database integrity with conventional facilities 
for record locking, atomic transactions, etc. In Microsoft 
SQL Server, the interface language between query fa- 
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cility211 and search engine 241 is Transact-SQL, which 
provides most of the functions of the standard ANSI SQL 
89 and ANSI SQL 92 languages, plus extensions for 
providing greater flexibility and prog ram inability. 
[0024] Fig. 3 illustrates some conventional functions 
300 of search engine 241 , Fig. 2, for processing a query 
transmitted from any of the client applications 21 0. SQL 
is a nonprocedural language because an SQL query is 
a specification of properties or predicates of a desired 
result, rather than a sequence of steps for obtaining the 
result. That is, a query such as SELECT year, quarter, 
sales FROM Narrow WHERE sales < (SELECT AVG 
(sales) FROM Narrow) ORDER BY year, quarter spec- 
ifies the properties of an output table. The columns of 
the output table correspond to the columns named year, 
quarter, and sales taken from an input table named Nar- 
row. The output-table rows (records) are to be ordered 
(i.e., sorted) by year and then by quarter within each 
year value. The records from the input table which ap- 
pear in the output are only those where the value of 
sales is less than the average value of all values of sales 
in the table named Narrow. The nested subquery SE- 
LECT AVG(sales) FROM Narrow generates a table hav- 
ing only a single column and a single row containing the 
average value of sales in the Narrow table. The manner 
and sequence in which the records of the input table are 
accessed, and other details of the procedure or plan for 
building the output table are not defined by the query 
itself. 

[0025] When search engine 241 receives a query, it 
parses the query into an internal or tokenized form, as 
shown in step 31 0. Validation step 320 ensures that the 
data named in the query actually exists in the database, 
and checks data and integrity constraints. It may expand 
some parts of the query, such as macros and views, at 
321 . Output 322 reports any errors back to the user or 
other source of the query. All but the most limited search 
engines perform extensive optimization upon the query, 
as indicated in step 330. Optimization may involve re- 
writing the query by combining or splitting portions of the 
query, rearranging operations and subqueries, etc., and 
other methods, such as sequencing accesses to the 
records of stored database tables, and modifying func- 
tions For each candidate execution strategy, they calcu- 
late a cost value representing the computing time or re- 
sources required to execute the query using this strate- 
gy, and then select one strategy among all the possible 
candidates. Although the art of designing these optimiz- 
ers is complex and arcane, those adept in it have the 
ability to adapt conventional optimizers so as to include 
new query functions of various types; designers of trans- 
lators for other, more procedural languages also routine- 
ly construct optimizers of this same general class. A sur- 
vey paper, M. Jarke and J. Koch, "Query Optimization 
in Database Systems," ACM Computing Surveys 16, 2 
(June 1 984), p. 1 1 1 , discusses the construction of data- 
base query optimizers in more detail. 
[0026] The output of step 330 is a query evaluation 



plan (or simply "plan") for answering the query. Step 340 
compiles this plan into a procedural form, usually repre- 
sented as a conventional function tree. Step 350 may 
then run a simple tree-traversal algorithm for executing 

5 the plan against the database objects. The output of 
step 350 is the result of the query, in the form of an output 
table returned to the source of the query. Search en- 
gines other than the one described herein may combine 
or divide the individual steps 300, or may omit or add 

10 steps. Another survey paper, G. Graefe, "Query Evalu- 
ation Techniques for Large Databases," ACM Comput- 
ing Surveys 25, 2 (June 1993), p. 73, hereby incorpo- 
rated by reference, addresses the subject of query ex- 
ecution, and cites a number of references providing ad- 

15 ditional description and discussion. Again, the steps of 
the newest search engines are specifically designed for 
easy extensibility to accommodate new syntax, new 
query function, optimization knowledge, and execution 
technology. 

20 

Pivot and Unpivot Operations 

[0027] Fig. 4 shows the structure of a pivot operation 
according to the invention. This operation fits into the 

25 hierarchy of SQL operations at the level of relational al- 
gebra. Those who design relational database systems 
and interfaces divide query processing into three levels. 
Because the mathematical theory of relations provides 
the conceptual framework for this type of databases, the 

30 first and second levels are frequently called the relation- 
al calculus and the relational algebra. 
[0028] The relational calculus, like any calculus, deals 
with a high-level description or specification of a desired 
result, without naming any operations, procedures, or 

35 other method for obtaining the result. That is, it merely 
expresses the definition of a desired result relation (ta- 
ble) in terms of existing relations in a database. The que- 
ry SELECT employee. name, department. name FROM 
employee, department WHERE employee.dept_id = de- 

40 partment.deptjd, for example, describes the properties 
and constraints of an output table in terms of one or 
more input tables in terms of a typical member of the 
result relation and a qualification representing the defin- 
ing property of the result members. The relational cal- 

45 cuius provides the foundation for a formal, exact under- 
standing of databases, tables ("relations"), and queries, 
and has found a commercial realization in the query 
components of the database language SQL, now an 
ANSI/ISO standard. Given the important role SQL plays 

50 in data-management products, extending database 
functionality for the real world requires that any added 
functionality should become a syntactically and seman- 
tically clean extension of the SQL language. 
[0029] Relational algebra is more operationally orient- 

55 ed (yet equivalent to) relational calculus. Operations or 
functions in relational algebra consume one or more in- 
put tables and produce an output table according to a 
rule. For example, the relational operation JOIN [em- 
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ployee.dept_id = department. dept_id] (employee, de- 
partment) combines the tables named employee and 
department along a common column or field named 
dept_id in both tables. (This is analogous to an operation 
such as addition, which consumes two numbers and 
produces a third, as, for example, the operation "4+5" 
produces "9".) Key characteristics of relational algebra 
are that: (1) operations consume and produce objects 
of the same type, namely relations; (2) operations can 
be nested into arbitrarily complex structures; and (3) 
new operations can be added. In the relational algebra, 
input objects not only have inputs, but may also carry 
tags denoting additional information. In the example im- 
mediately above, the join operation not only specifies 
the two relational-algebra expressions, namely the two 
tables (employee, department) to be joined, but also 
names a "join predicate" specifying how they are to be 
joined: along equal values of a particular column in each 
table, [employee. dept_id = department. dept_id]. 
[0030] Some very useful query operations are difficult 
to express at the relational-calculus level, yet they inte- 
grate easily and cleanly into the relational-algebra level. 
For example, OUTER JOIN, a variant of the relational 
JOIN operation, does not fit easily or cleanly into the 
simple SELECT... FROM... WHERE query syntax. 
Therefore, ANSI/ISO permit a limited set of relational- 
algebra expressions in place of tables in the from 
clause, e.g., SELECT employee. name department, 
name FROM employee LEFT OUTER JOIN department 
ON employee. dept_id = department. dept_id. That is, 
there is a precedent for extending a relational-calculus 
query with a relational-algebra expression, although 
such extensions have been thus far restricted to varia- 
tions of JOIN operations. Relational-algebra operations 
often participate in the optimization of queries having 
selections, projections, aggregations, and other nonpro- 
cedural specifications at the relational-calculus level, as 
in block 330, Fig. 3. 

[0031 ] Query-execution plans constitute the third and 
lowest level of query processing. Although the nesting 
of relational-algebra operations may indicate an order 
of execution, algorithms or sets of particular instructions 
for producing intermediate results occur at the level of 
execution plans, rather than at the higher levels. For ex- 
ample, there are three basic methods for performing re- 
lational JOIN operations: nested loops, merge-join, and 
hash-join; and each method has a large number of var- 
iants. Execution plans clearly indicate the choice among 
such alternatives, and are formulated at the lowest level 
of query processing in block 340, Fig. 3. 
[0032] Because relational query processing is defined 
very precisely and within a definite structural framework, 
it is important to define any new functionality at all three 
levels: language extensions, relational-algebra opera- 
tions, and execution plans. The invention may provide 
the pivot and unpivot functions as new relational-alge- 
bra operations that participate explicitly in SQL queries, 
as extensions to the language. 



[0033] The formal definition of a pivot operation, for 
an input table-expression in first normal form that is a 
valid query expression, is: Table. PIVOT 
(<value_column> FOR <pivot_column> IN 

5 (<pivot_list>)); the output pivoted table then is also aval- 
id first-normal-form table. The text between the outer- 
most parentheses constitutes the specification of the 
pivot operation. The first two columns in the pivot spec- 
ification must be columns in the pivot operation's input 

10 table. These columns will not appear in the pivot oper- 
ation's output table. Instead, each value in the pivot list 
within the pivot specification defines a new column in 
the pivot operation's output table. In the input table, el- 
ements in the pivot list appear as values in the pivot col- 

15 umn. Corresponding values in the value column be- 
come values in the new columns in the output table. All 
columns of the input table not included in the pivot spec- 
ification, called "grouping columns," are carried over to 
the output table. 

20 [0034] In the example 400 set forth in Fig. 4, pivoting 
input table 41 0 in accordance with specification 420 pro- 
duces output table 430. Pivot column 41 1 , named Quar- 
ter in the input table 410 named Narrow, becomes four 
columns 431 , 432, 433, and 434 in the output table 430. 

25 The names of these columns are the four distinct values, 
Spring, Summer, Fall, Winter, that appear as values in 
column 411, and that also appear in the value list follow- 
ing the keyword IN in 420. The sales numbers in value 
column 412 appear as values in corresponding ones of 

30 the four columns 431 -434, but pivoted or rotated, so that 
sales figures for the same region and year are in the 
same row. Grouping columns 413-414 appear as col- 
umns 435-436 in output 430. In the output, the rows are 
grouped by equal values of the first grouping column 

35 413, and then by equal values of the second grouping 
column 414, just as though specification 420 had con- 
tained an SQL clause of the form GROUP BY Region, 
Year. In this example, the effect of the pivot operation is 
to modify the perspective along which the data is 

40 viewed. Input table 410 presents data trends primarily 
by year for the Narrow regions of a company, whereas 
output table 430 allows seasonal tracking by quarters. 
(It should be recalled here that the rows in an relational 
table do not have names, and have no particular order. 

45 Columns do have names and are sorted - that is, they 
are presented in the order their names appear in a que- 
ry.) The pivot operation converts an input table having 
relatively many rows and relatively few columns into a 
result table having fewer rows and more columns. 

50 [0035] The pivoted columns in the output table have 
the same data type (numeric, varchar, etc.) as the data 
in the value column of the input table. The value column, 
pivot column, and pivoted columns comprise simple da- 
ta, rather than computed expressions. The order of the 

55 columns in both tables is not significant, as in ANSI SQL; 
columns can be referenced only by name, not by posi- 
tion. Although table 430 is shown sorted by values of 
grouping columns Region and Year, the pivot operation 
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does not imply any particular sorting or ordering of the 
rows. 

[0036] As mentioned above, a row in the input table 
does not appear in the output if its value does not appear 
in the pivot list. The input-table rows are grouped by 
equal values of any grouping columns, with respect to 
the definition of equality. Within each group, each row 
of the input table has a mutually distinct value in the pivot 
column. Each group results in one output row. For output 
columns not having a corresponding input row, the value 
is NULL, a special value defined in SQL. 
[0037] Fig. 5 is a flowchart 500 of the steps carried 
out by modules 300, Fig. 3, of search engine 241 in Fig. 
2 for a pivot operation. Block 51 0 receives a query from 
a user at a client terminal 1 20, Fig. 1 , or from some other 
source as described herein. Step 520 identifies or se- 
lects which table 261 in database 260 is to serve as the 
input table of the operation. Step 521 identifies which 
column of the input table is to be the pivot column, step 
522 identifies from the pivot list which pivot-column val- 
ues participate in the pivot, and step 523 selects which 
column of the input is the value column. Step 530 con- 
structs the output as another table 261. Step 531 em- 
places a separate pivoted column for each data-item 
value in the pivot list. Step 532 constructs the grouping 
columns, if any. (As mentioned previously, these are any 
additional columns of the input table not identified in the 
pivot specification.) Step 540 inserts the data-item val- 
ues of the value column into the rows of the output table 
as described previously; one method is by transposition, 
as indicated by step 541. Another way to express this 
transposition is that each data item in the value column 
is placed into one of the pivoted columns, namely, that 
column whose name is the same as the data value in 
the pivot column of the input table. Step 550 groups the 
output-table rows by equal values of any grouping col- 
umns. Finally, step 560 stores the output table in data- 
base 260, Fig. 2. 

[0038] The unpivot operation is the inverse of the pivot 
operation, and is formally defined as (table_expression| 
query_expression>. UNPIVOT (<value_column> FOR 
<pivot_column> IN (<column_list>). The meanings of 
the terms are the same as for the pivot operation. Ap- 
plying a pivot and an unpivot operation having the same 
specification to an input table restores the input table to 
its original state. In the example shown in Fig. 4, apply- 
ing the unpivot operation 440 to pivoted table 430 re- 
stores table 41 0; the two named columns Sales 412 and 
Quarter 411 replace columns 431-434. 
[0039] Other database-system operations can be 
considered as inverses of each other, such as the group- 
ing/splitting and merging/collapsing pairs mentioned in 
M. Gyssens, et al., "Tables as a Paradigm for Querying 
and Restructuring", PROCEEDINGS 1996 ACM SIG- 
MOD INTL. CONF. ON MANAGEMENT OF DATA, Mon- 
treal, Que., Canada, 3-6 June 1 996, pages 93-1 03. Piv- 
ot/unpivot are also inverses of each other. 
[0040] For each row in an input table, the unpivot op- 



eration generally produces one row of an output table 
per pivoted column. (However, a null value in a pivoted 
column does not generate an output row.) All columns 
in the pivot list must have the same data type in the input, 

5 and the entries in the value column of the output will 
have this type. Unpivoting a table increases the number 
of its rows and decreases the number of columns. 
Again, although Fig. 4 shows table 41 0 sorted by group- 
ing-column values, the unpivot operation implies no row 

10 sorting in the output. 

[0041] Fig. 6 is a flowchart 600 of the steps carried 
out by modules 300, Fig. 3, of search engine 241 , Fig 2 
for an unpivot operation. Step 61 0 receives the unpivot 
operation and its specification. Because unpivot is de- 

15 fined to be the inverse of pivot and to restore a pivoted 
table exactly to its unpivoted form, the specification of 
an unpivot is not complementary to that for a pivot, but 
rather has exactly the same form as that of the specifi- 
cation which created the pivoted table in the first place, 

20 as shown at 440 in Fig. 4. Again, step 610 may receive 
the operation from a user query or any other source. 
Step 620 identifies or selects the pivoted table such as 
261 to be unpivoted. This table need not have been ac- 
tually pivoted in a previous operation, but it normally will 

25 have been; that is, the pivot operation is generally used 
to achieve any initial rotation of perspectives, and un- 
pivot is generally only used to restore a table to an orig- 
inal unpivoted form in a clean, simple manner. Step 621 
uses the specification's pivot list to identify which col- 

30 umns are the pivoted columns to be rotated or trans- 
posed. Steps 622 and 623 identify the names of the val- 
ue column and the pivot column. These names are in- 
cluded in the specification because they do not appear 
anywhere within the pivoted table (at least, unless a pre- 

35 vious pivot had kept a side table retaining this informa- 
tion). 

[0042] Step 630 constructs the pivot table which is to 
be produced by the unpivot operation. Steps 631 and 

632 form the pivot and value columns in the pivot table, 
40 using the names supplied in steps 622 and 623. Step 

633 builds grouping columns in the pivot table, one for 
each of the pivoted-table columns not included in the 
unpivot specification received in step 610. Step 640 
transposes the data items from the pivoted table into the 

45 unpivoted table constructed in the preceding steps. 
Names of the pivoted columns become data items in dif- 
ferent rows, and the data items in the pivoted column 
go into the new value column, in the rows having respec- 
tively the same pivot-column values as the name of the 

50 pivoted column thatthey were in, in the original (pivoted) 
table. Step 650 groups rows by equal values of the 
grouping-column rows. Step 660 stores the table away 
in database 260, Fig. 2. 

[0043] Correlation variables are not permitted within 
55 the specification of pivot and unpivot operations, be- 
cause the pivot, value, and pivoted columns are simple 
data, and not computed values. These new operations 
have no bearing upon whether or which correlation var- 
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iables are permissible in a query expression to which 
the operations are applied. If ANSI SQL permits defining 
table and column aliases for a query expression in which 
a pivot or unpivot operation does not occur, then it is 
acceptable to define such aliases for the query expres- 
sion including a pivot/unpivot operation, but not for the 
query expression excluding the operation. For example, 
if Tablel AS Table2 (coM, col2) is permissible, then 
Tablel. PIVOT (...) AS Table2 (coM, col2, ...) is accept- 
able, but Tablel AS Table2 (coM , col2). PIVOT (...) is not. 
[0044] The pivot and unpivot operations may employ 
any number of conventional optimization techniques in 
block 330, Fig. 3. Because these operations are part of 
the relational-algebra level, an algebraic query optimiz- 
er may be the most appropriate vehicle for realizing op- 
timization techniques. Other optimization frameworks 
may be applicable as well. 

[0045] Some additional optimization techniques may 
employ specific properties of the new operations. Obvi- 
ously, a neighboring pair of pivot and unpivot operations 
may cancel each other, and may then be removed from 
a query. An optimizer should recognize thatthe grouping 
columns in the pivoted output table functionally deter- 
mine the pivot and value columns, and therefore form a 
relational key of the result table. (This is very similar to 
the grouping columns in a conventional GROUP BY op- 
eration.) In an unpivot output table, the grouping col- 
umns together with the pivot column functionally deter- 
mine the value column. These properties can assist in 
estimating the number of output rows for selectivity es- 
timation and query-cost calculation for comparing alter- 
native execution plans. They also may find utility in gen- 
erating conditions for applying rewrite rules in simplify- 
ing the execution of a query. If a table is vertically parti- 
tioned, an operation to reassemble complete rows and 
a subsequent unpivot may cancel each other, eliminat- 
ing both operations. 

[0046] A conceptual similarity of the pivot operation to 
an SQL GROUP BY clause allows many techniques and 
rules for optimizing queries having that clause to serve 
as well for the new operations. Typical examples in- 
clude: (1) pulling a pivot above a join, so as to reduce 
the grouping input's size, or to enable more efficient join 
algorithms; (2) pushing a pivot below a join to reduce 
the join input or to employ more efficient execution plans 
for the pivot; (3) merging two adjacent pivots, possibly 
effectively eliminating one of them; and (4) splitting a 
pivot into two parts, then pushing one of the parts 
through a join or across a process boundary, as a local/ 
global aggregation in a parallel execution environment. 
In general, a query predicate on the grouping columns 
and a projection operation-including expressions that 
compute additional columns-can be moved through (ei- 
ther above or below) a pivot/unpivot operation in the 
same manner as a grouping operation. 
[0047] Certain query predicates are more efficient to 
implement-and also easier to express-when treated as 
predicates (i.e., qualifications) against a pivot result ta- 



ble. For example, comparing two pivoted columns to 
each other is straightforward to express and efficient to 
implement, whereas the same predicate applied to the 
pivot input table requires complex, inefficient nested 

5 queries. Therefore, rewriting the query to include a pivot/ 
select/unpivot sequence of operations can be used to 
optimize such queries. For example, consider a query 
to select table rows in which Sales in the Fall exceeds 
Sales in the Spring in table 410, Fig. 4. Pivoted table 

10 430 can accommodate this query as a comparison be- 
tween the Spring and Fall columns 431 and 433, where- 
as the original table 410 requires joining the table to it- 
self in order to perform the comparison. Using the tables 
of Fig. 4, such a larger query including pivot and unpivot 

15 operations (in conventional multiple-line format) might 
be: 

(SELECT* FROM 

Narrow.PIVOT (Sales FOR Quarter IN (Spring, Sum- 
mer, Fall, Winter)) 
20 WHERE Fall_Sales>Spring_Sales) 

.UNPIVOT (Sales FOR Quarter IN (Spring, Summer, 
Fall, Winter)) 

[0048] Execution plans useful for block 340, Fig. 3, 
can be derived by those skilled in the art from conven- 
es tional plans for grouping operations. In particular, plans 
based upon looping, indexing, streams, sorting, and 
hashing come readily to mind. Early-aggregation sorting 
and hybrid hashing are useful variants. Pivot/unpivot op- 
erations are amenable to parallel-execution environ- 
30 ments, including parallel algorithms such as shared- 
memory, distributed-memory, shared-disk, and cluster 
machines. Local/global aggregation has already been 
mentioned as a possibility. 

[0049] Unpivot operations require only a single-input, 
35 single-output plan that produces multiple output records 
for each input record. This operation can be easily exe- 
cuted in parallel on shared-memory, distributed-memo- 
ry, shared-disk, and cluster machines. 



[0050] A number of variants and extensions to the 
above embodiment may be useful for some applica- 
tions, either alone or in combination with each other. The 
45 most obvious, of course, are the replacement or aug- 
mentation of notational conventions, such as the dot in- 
vocation separator, and the rearrangement of compo- 
nents. 

[0051] The pivot/unpivot operations as thus far de- 
50 scribed place limitations upon column names in the piv- 
oted or output table. Column names in standard SQL 
must be character strings without spaces. Because col- 
umn values may have spaces, and pivot changes values 
into names, a method can easily be devised to employ 
55 quoted identifiers and literals as column names. Like- 
wise, it would be simple to represent column values hav- 
ing data types other than character strings as printable 
and readable representations for column names. Con- 
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ventional name manipulations, such as concatenations 
of names might be useful. For example, a pivot list might 
contain column aliases using a keyword such as SQL 
AS. (In Fig. 4, if the Quarter values were "1 " through "4" 
instead of season names, the specification of 420 might 
read (Sales FOR Quarter IN (1 AS "Spring", 2 AS "Sum- 
mer", 3 AS "Fall", 4 AS "Winter"). In addition, AS might 
be used to rename pivot-result columns in any context, 
and user-defined functions could be supplied for con- 
verting complex column names, or for conforming 
names to specific limitations of an SQL implementation. 
[0052] Semantic extensions might include pivoting 
and unpivoting multiple columns in a single step. For ex- 
ample, operation 450 in Fig. 4 replaces the three col- 
umns 411,41 2, and 41 4 with eight columns, instead of 
the four columns 431-434 of result table 430. That is, 
the set of pivot columns represent a Cartesian or outer 
product of all the pivot lists. A convention for naming the 
pivoted columns might merely involve concatenating the 
names, such as Sales_1 996_Spring, etc. A multicolumn 
unpivot operation with the same specification could de- 
code such names back into their original form, so as to 
provide a true inverse for this extension. A further ex- 
tension would permit multicolumn pivoting in steps. For 
example, it might be desired to apply a further pivot to 
already pivoted table 430 about column 436, to produce 
the eight columns described above. Rather than unpiv- 
oting table 430 and then applying a multicolumn pivot, 
an extended form allows a list of columns in place of the 
valuecolumn, e.g., Wide. PIVOT ((Spring, Summer, Fall, 
Winter) FOR Year IN (1 996, 1 997)). Optimizer 340 and 
compiler 350 can easily collapse these uperations into 
a single plan for execution. 

[0053] The pivot operation (but not unpivot) can sup- 
port conventional SQL aggregation or grouping func- 
tions such as MIN, SUM, AVG, and even COUNT, for 
the value column at step 540. In that case, the limitation 
to a single row per group can be lifted. Of course, the 
type of the new column might differ from that of the orig- 
inal. The following example, based upon Fig. 4, illus- 
trates a query using aggregation: 
(SELECT Year, Quarter, Sales FROM Narrow) 
.PIVOT (SUM(Sales) FOR Quarter IN (Spring, Summer, 
Fall, Winter) 

This query consolidates Sales for the East and west re- 
gions into a single sum representing the entire company 
for each Year. In versions where grouping functions are 
allowed, the implementation could specify the implicit 
application of a particular function, such as SUM, in all 
cases where a pivot operation would otherwise produce 
duplicate primary keys in different rows of the pivoted 
table. Pivots with grouping cannot be reversed, because 
the aggregation loses information detail; grouped output 
in standard SQL cannot be reversed for the same rea- 
son. Although this extension prevents unpivotfrom func- 
tioning as a true inverse, an embodiment preserves this 
capability by adding an internal "side table" that saves 
all the original values. 



[0054] Another powerful extension adds a capability 
for replacing the list of literal column names in a pivot or 
unpivot operation with a SELECT query. More complex 
processing would involve running the auxiliary query 

5 first, then binding the list of pivoted columns using the 
result of the auxiliary query; that is, the auxiliary query 
requires interleaved compilation and execution in blocks 
340 and 350, Fig. 3. The execution requires computing 
the query expression that is to be pivoted, as well as 

10 running a query against the result. 

[0055] The pivot specification might omit the pivot list 
entirely, supplying a default query instead. For example, 
omitting the clause IN (Spring, Summer, Fall, Winter) 
from query 420 could substitute a default query SELECT 

15 DISTINCT Quarter FROM Narrow. Because this causes 
query 420 to reference the input table twice, it would be 
useful to introduce a dedicated name for an operation's 
input table, analogously to the name "this" in C ++ . Op- 
eration 420 would then become: 

20 Narrow.PIVOT (Sales FOR SELECT DISTINCT Quarter 
FROM INPUT). 

[0056] Instead of requiring a pivot list, the unpivot op- 
eration might allow a specification of all but the pivoted 
columns in the operation's input. In the example 400 as 
25 modified above, the inverse operation could be speci- 
fied as (see 440, Fig. 4: 

Wide. UNPIVOT (Sales FOR Quarter IN (Spring, Sum- 
mer, Fall, Winter)) or as (460, Fig. 4): 
Wide.UNPIVOT (Sales OVER (Region, Year)). 

30 Supporting OVER in this context necessitates determin- 
ing the set of pivoted columns from the input table, and 
thus requires the ability to process auxiliary queries, as 
described above. The IN and OVER clauses can be 
combined, permitting one or more columns to be a piv- 

35 oted column as well as a grouping column. A situation 
where this might make sense from the application's per- 
spective is the inclusion of Spring sales in each output 
row, in order to allow computation of sales growth since 
the first quarter for each subsequent quarter. 

40 [0057] In some tables, a set of columns can be more 
or less orthogonal or independent; for example, col- 
umns named "City" and "Month" are likely to have table 
entries for all cities for all months. Other column sets are 
hierarchical-such a "Locations" table having "State", 

45 "City", and "Store" columns--and their data is sparse; 
that is, very few cities will occur in multiple states, and 
few cities will have multiple stores. In the latter case, the 
use of two IN clauses leads to ungainly syntax and se- 
mantics in a pivot operation. However, employing a list 

50 of pivot columns instead of a single pivot column amel- 
iorates this problem. ANSI SQL's concept of "row val- 
ues" is appropriate to this case. Typically, although not 
always, it is more convenient to specify a query as the 
pivot list, rather than a list of literal column names. An 

55 exemplary form might be Locations. PIVOT (SalesVol- 
ume FOR (City, Store) IN (SELECT City, Store FROM 
Outlets)). 

[0058] The pivot and unpivot operations could also 
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find utility in the internal operation of query processors 
300, Fig. 3 In addition, referential-integrity constraints 
need to be enforced only for deleted candidate keys and 
new foreign keys; using pivot/unpivot or a similar rota- 
tion could collapse deletion and insertion items pertain- 
ing to the same key value, and thus potentially eliminate 
some integrity checks as redundant. Moreover, in a con- 
ventional query having a very large IN clause, an inter- 
nal unpivot operation invoked implicitly by the search 
engine can map a single very complex row containing 
many literals or parameters as columns into a set of 
rows that can be matched against database tables, us- 
ing conventional join methods such as loops, index, 
merge, and hash join, and their parallel-processing var- 
iants. Similar internal invocations of pivot/unpivot oper- 
ations may be useful in OR and UNION queries, which 
are often equivalent to IN clauses. 



Claims 

1. A method performed by a computer (500) of trans- 
forming data from an unpivoted input relational da- 
tabase table (41 0) into a pivoted output table (430), 

characterized in that all of the following 
steps are performed entirely within a relational da- 
tabase management system (200) for processing 
tables having rows and columns of items containing 
data-value items, and having items containing col- 
umn names stored separately from and in a different 
format from that of the data-value items, without 
converting to and from a different overall table for- 
mat, the steps performed by the computer compris- 
ing: 

selecting (521) the separately stored name of 
a first ofthe columns of the input table as a pivot 
column; 

selecting (523) the separately stored name of 
a second of the columns of the input table as a 
value column; 

converting (531) a set of the items stored as 
data values in the pivot column directly into 
items stored as column-name items in the out- 
put table denoting pivoted columns in the out- 
put table; 

placing (540) items stored as data values in the 
pivot column into respective data-value items 
in corresponding different ones of the pivoted 
columns of the output table; 
storing (560) the output table directly in the da- 
tabase management system, without convert- 
ing it to or from a different format. 

2. The method of claim 1 characterized in that the 

placing step comprises, for each data-value item in 
the value column located in the same row of the in- 
put table as a particular one of the set of data-value 



items in the pivot column, placing the particular one 
data-value item into a certain one of the pivoted col- 
umns of the pivoted outputtable the certain one piv- 
oted column having a name corresponding to the 
5 particular one data-value item in the pivot column. 

3. The method of claim 1 characterized in a further 
step of selecting (522) certain ones of the set of da- 
ta-value items in the pivot column as a pivot list, and 

10 wherein the converting step converts only those da- 
ta-value items in the pivot list into the column-name 
items. 

4. The method of claim 3 characterized in that the 

15 converting step does not convert any rows in the 
input table having NULL data-value items in the piv- 
ot column. 

5. The method of claim 1 characterized in that the 
20 input table has at least one column (413) other than 

the pivot and value columns. 

6. The method of claim 5 characterized in grouping 
(532) the rows of the output table by equal values 

25 of the data-value items in the at least one other col- 
umn. 

7. A method (600) performed by a computer of trans- 
forming data from a pivoted input relational data- 

30 base table (430) into an unpivoted output table 
(410), 

characterized in that all of the following 
steps are performed entirely within a relational da- 
tabase management system (200) for processing 
35 tables having rows and columns of items containing 
data values, and having items containing column 
names stored separately from and in a different for- 
mat from that of the data-value items, without con- 
verting to and from a different overall table format, 
40 the steps performed by the computer comprising: 

selecting (623) the separately stored name of 
a first of thecolumnsof the inputtable as a pivot 
column; 

45 selecting (621 )a plurality of the separately 

stored names of the columns of the input table 
as a pivot list; 

creating (632) in the output table a value col- 
umn having a selected name stored in a col- 
50 umn-name item and a plurality of separately 

stored data-value items; 
placing (640) items stored as column-name 
items in the pivot list into respective data-value 
items in corresponding different ones of the val- 
55 ue column of the output table; 

storing (660) the output table directly in the da- 
tabase management system, without convert- 
ing it to or from a different format. 
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from one of the clients contains an unpivoting oper- 
ation specifying 

a pivoted relational input table (430) having 
5 rows and columns of data values and having 

column names stored separately from the data 
values in the columns, 
a name (411) for a value column, 
a name (412) for a pivot column, and 
10 a pivot list including names of at least some of 

the columns (431-434) in the pivoted input ta- 
ble, 

characterized in that the search engine 
15 transposes (600) the column names in the pivot list 
about the pivot column, converting those column 
names into separately stored and formatted data 
values so as to construct an unpivoted output table 
directly from the input table without converting ei- 
20 ther table to or from a different format. 



8. The method of claim 7 characterized in that the 

placing step comprises, for each particular data-val- 
ue item in each particular column of the input-table 
columns in the pivot list, placing the particular data- 
value item into the a data-value item of the value 
column of the unpivoted output table in a row which 
also contains a data-value item in the pivot column 
corresponding to the particular column of the input 
table. 

9. The method of claim 7 characterized in that the 
input table has at least one column (435) other than 
the columns in the pivot list. 

10. The method of claim 9 characterized in that the 

grouping step groups the rows of the output table 
by equal values of the data-value items in the at 
least one other column. 

11. A relational database system (200) having a 
number of clients (210) and a search engine (240) 
including modules for parsing (310), optimizing 
(330), and executing (350) a query (420, 450) from 
one of the clients containing a pivoting operation 
specifying 

a relational input table (410) having rows and 
columns of data values and having column 
names stored separately from the data values 
in the columns, 

a name of a pivot column (411) in the input ta- 
ble, and 

a name of a value column (412) in the input ta- 
ble, 

characterized in that the search engine 
transposes (500) data values in the value column 
about the pivot column, converting at least some of 
the data values into separately stored and format- 
ted column names so as to construct a pivoted out- 
put table directly from the input table without con- 
verting either table to or from a different format. 

12. The system of claim 11 where the pivoting operation 
further specifies a pivot list (522) of data values in 
the pivot column, 

characterized in that the data values in the pivot 
column are transposed based upon the data items 
in the pivot list. 

13. The system of claim 12 where the input table in- 
cludes columns (413) other than the pivot and value 
columns, 

characterized in that the search engine groups 
(550) rows of the output table by equal values of the 
data-value items in the other columns. 

14. The system of claim 12 where a query (440, 460) 



15. A relational database system (200) having a 
number of clients (210) and a search engine (240) 
including modules for parsing 310), optimizing 
25 (330), and executing (350) a query (440, 460) from 
one of the clients containing an unpivoting opera- 
tion specifying 



a relational input table (430) having rows and 
30 columns of data values and having column 

names stored separately from the data values 
in the columns, 

a name for a pivot column (412), and 
a pivot list including names of at least some of 
35 the columns (431-434) in the input table, 

characterized in that the search engine 
transposes (600) the column names in the pivot list 
about the pivot column, converting these names in- 
40 to separately stored and formatted data values so 
as to construct a pivoted output table directly from 
the input table without converting either table to or 
from a different format. 

45 16. The system of claim 15 where the input table in- 
cludes columns (435) other than the pivot and value 
columns, 

characterized in that the search engine groups 
rows of the output table by equal values of the data- 
50 value items in the other columns. 

17. A medium (133) carrying representations of instruc- 
tions for causing a suitably programmed computer 
to perform a method (500) of transforming data from 
55 an unpivoted input relational database table (410) 
into a pivoted output table (430), 

characterized in that all of the following 
steps are performed entirely within a relational da- 
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tabase management system (200) for processing 
tables having rows and columns of items containing 
data-value items, and having items containing col- 
umn names stored separately from and in a different 
format from that of the data-value items, without 5 
converting to and from a different overall table for- 
mat, the steps comprising: 

selecting (521) the separately stored name of 

a first of the columns of the input table as a pivot 10 

column; 

selecting (523) the separately stored name of 
a second of the columns of the input table as a 
value column; 

converting (531) a set of the items stored as 15 
data values in the pivot column directly into 
items stored as column-name items in the out- 
put table denoting pivoted columns in the out- 
put table; 

placing (540) items stored as data values in the 20 
pivot column into respective data-value items 
in corresponding different ones of the pivoted 
columns of the output table; 
storing (560) the output table directly in the da- 
tabase management system, without convert- 25 
ing it to or from a different format. 

18. The medium of claim 1 7 further carrying represen- 
tations of instructions for causing a suitably pro- 
grammed computer to perform a method of trans- 30 
forming data from a pivoted input relational data- 
base table into an unpivoted output table in the 
same relational database system, 

characterized in that all of the following 
steps are performed entirely within a relational da- 35 
tabase management system for processing tables 
having rows and columns of items containing data 
values, and having items containing column names 
stored separately from and in a different format from 
that of the data-value items, without converting to 40 
and from a different overall table format, the steps 
comprising: 

selecting the separately stored name of a first 
of the columns of the input table as a pivot col- 45 
umn; 

selecting a plurality of the separately stored 
names of the columns of the input table as a 
pivot list; 

creating in the output table a pivot column hav- 50 
ing a selected name stored in a column-name 
item and a plurality of separately stored data- 
value items; 

converting the column-name items in the pivot 
list to data-value items in the pivot column; 55 
creating in the output table a value column hav- 
ing a selected name stored in a column-name 
item and a plurality of separately stored data- 



value items; 

placing items stored as column-name items in 
the pivot list into respective data-value items in 
corresponding different ones of the value col- 
umn of the output table; 
storing the output table directly in the database 
management system, without converting it to or 
from a different format. 

19. A medium (133) carrying representations of instruc- 
tions for causing a suitably programmed computer 
to perform a method (600) of transforming data from 
a pivoted input relational database table (430) into 
an unpivoted output table (41 0), 

characterized in that all of the following 
steps are performed entirely within a relational da- 
tabase management system (200) for processing 
tables having rows and columns of items containing 
data values, and having items containing column 
names stored separately from and in a different for- 
mat from that of the data-value items, without con- 
verting to and from a different overall table format, 
the steps comprising: 

selecting (623) the separately stored name of 
a first of the columns of the input table as a pivot 
column; 

selecting (621 )a plurality of the separately 
stored names of the columns of the input table 
as a pivot list; 

creating (632) in the output table a value col- 
umn having a selected name stored in a col- 
umn-name item and a plurality of separately 
stored data-value items; 
placing (640) items stored as column-name 
items in the pivot list into respective data-value 
items in corresponding different ones of the val- 
ue column of the output table; 
storing (660) the output table directly in the da- 
tabase management system, without convert- 
ing it to or from a different format. 



Patentanspruche 

1. Von einem Computer (500) durchgefuhrtes Verfah- 
ren zum Transformieren von Daten von einer un- 
pivotisierten Eingangstabelle (410) einer relationa- 
len Datenbank in eine pivotisierte Ausgangstabelle 
(430), 

dadurch gekennzeichnet, daB alle folgen- 
den Schritte vollstandig innerhalb des relationalen 
Datenbankmanagementsystems (200) ausgefuhrt 
werden, urn Tabellen zu verarbeiten, die Zeilen und 
Spalten von Eintragen mit Datenwert-Eintragen so- 
wie getrennt von den und in einem anderen Format 
als die Datenwert-Eintrage gespeicherte Spalten- 
namen aufweisen, ohne daB auf ein und von einem 
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anderen Gesamttabellenformat konvertiert wird, 
mit folgenden vom Computer ausgefuhrten Schrit- 
ten: 

Auswahlen (521) des getrennt gespeicherten 
Namens einer ersten Spalte der Eingangsta- 
belle als Pivot-Spalte, 

Wahlen (523) des getrennt gespeicherten Na- 
mens einerzweiten Spalte der Eingangstabelle 
als Wertspalte, 

Umwandeln (531 ) eines Satzes von Eintragen, 
die als Datenwerte in der Pivot-Spalte gespei- 
chert sind, direkt in Eintrage, die als Spalten- 
namen-Eintrage in der Ausgangstabelle ge- 
speichert sind, die pivotisierte Spalten in der 
Ausgangstabelle benennen, 
Anordnen (540) von Eintragen, die als Daten- 
werte in der Pivot-Spalte gespeichert sind, in 
entsprechende Datenwert-Eintrage in entspre- 
chend unterschiedlichen pivotisierten Spalten 
der Ausgangstabelle, und 
Speichern (560) der Ausgangstabelle direkt in 
dem Datenbankmanagementsystem, ohne sie 
in ein anderes oder aus einem anderen Format 
zu konvertieren. 

2. Verfahren nach Anspruch 1, dadurch gekenn- 
zeichnet, daB der Anordnungsschritt fur jeden Da- 
tenwert-Eintrag in der Wertspalte, der in der glei- 
chen Zeile der Eingangstabelle wie ein bestimmter 
aus dem Satz an Datenwert-Eintragen in der Pivot- 
Spalte angeordnet ist, ein Anordnen des bestimm- 
ten einen Datenwert-Eintrags in einer gewissen der 
pivotisierten Spalten der pivotisierten Ausgangsta- 
belle umfaBt, wobei die gewisse pivotisierte Spalte 
einen Namen aufweist, der dem bestimmten einen 
Datenwert-Eintrag in der Pivot-Spalte entspricht. 

3. Verfahren nach Anspruch 1, gekennzeichnet 
durch einen weiteren Schritt zum Auswahlen (522) 
gewisser aus dem Satz an Datenwert-Eintragen in 
der Pivot-Spalte als Pivot-Liste, wobei der Um- 
wandlungsschritt lediglich Datenwert-Eintrage in 
der Pivot-Liste in die Spaltennamen-Eintrage um- 
wandelt. 

4. Verfahren nach Anspruch 3, dadurch gekenn- 
zeichnet, daB der Umwandlungsschritt keine Zei- 
len in der Eingangstabelle mit NULL- Datenwert- 
Eintragen in die Pivot-Spalte umwandelt. 

5. Verfahren nach Anspruch 1, dadurch gekenn- 
zeichnet, daB die Eingangstabelle mindestens ei- 
ne andere Spalte (413) als die Pivot- und die Wert- 
spalte aufweist. 

6. Verfahren nach Anspruch 5, gekennzeichnet 
durch ein Gruppieren (532) der Zeilen der Aus- 



gangstabellen im Hinblick auf gleiche Werteder Da- 
tenwert-Eintrage in der genannten mindestens ei- 
nen anderen Spalte. 

5 7. Von einem Computer ausgefuhrtes Verfahren (600) 
zum Transformieren von Daten von einer pivotisier- 
ten Eingangstabelle (430) einer relationalen Daten- 
bank in eine unpivotisierte Ausgangstabelle (410), 
dadurch gekennzeichnet, daB alle folgen- 

10 den Schritte direkt innerhalb eines relationalen Da- 
tenbankmanagementsystems (200) ausgefuhrt 
werden, urn Tabellen zu verarbeiten, die Zeilen und 
Spalten von Eintragen mit Datenwerten sowie Ein- 
trage mit Spaltennamen, die getrennt von den und 

15 in einem anderen Format als die Datenwert-Eintra- 
ge gespeichert sind, aufweisen, ohne daB eine 
Konvertierung in ein anderes oder aus einem ande- 
ren Gesamttabellenformat durchgefuhrt wird, mit 
den folgenden vom Computer ausgefuhrten Schrit- 

20 ten: 

Auswahlen (623) des getrennt gespeicherten 
Namens einer ersten der Spalten der Ein- 
gangstabelle als Pivot-Spalte, 
25 Auswahlen (621) mehrerer der getrennt ge- 

speicherten Namen der Spalten der Eingangs- 
tabelle als Pivot-Liste, 

Erzeugen (632) einer Wertspalte in der Aus- 
gangstabelle mit einem ausgewahlten Namen, 

30 der in einem Spaltennamen-Eintrag gespei- 

chert ist, und mit mehreren getrennt gespei- 
cherten Datenwert-Eintragen, 
Anordnen (640) von Eintragen, die als Spalten- 
namen-Eintrage in der Pivot-Liste gespeichert 

35 sind, in entsprechenden Datenwert-Eintragen 

in entsprechend unterschiedlichen der Wert- 
spalte der Ausgangstabelle, und 
Speichern (660) der Ausgangstabelle direkt in 
dem Datenbankmanagementsystem, ohne 

40 daB sie in ein anderes oder aus einem anderen 

Format konvertiert wird. 

8. Verfahren nach Anspruch 7, dadurch gekenn- 
zeichnet, daB der Anordnungsschritt fur jeden be- 

45 stimmten Datenwert-Eintrag in jeder bestimmten 
Spalte der Eingangstabellen-Spalten in der Pivot- 
Liste ein Anordnen des bestimmten Datenwert-Ein- 
trags in einem solchen Datenwert-Eintrag der Wert- 
spalte der unpivotisierten Ausgangstabelle in einer 

50 Zeile umfaBt, die auch einen Datenwert-Eintrag in 
der Pivot-Spalte entsprechend der bestimmten 
Spalte der Eingangstabelle enthalt. 

9. Verfahren nach Anspruch 7, dadurch gekenn- 
55 zeichnet, daB die Eingangstabelle mindestens ei- 
ne andere Spalte (435) als die Spalten in der Pivot- 
Liste aufweist. 
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10. Verfahren nach Anspruch 9, dadurch gekenn- 
zeichnet, daB ein Gruppierungsschritt die Zeilen 
der Ausgangstabelle im Hinblick auf gleiche Werte 
der Datenwert-Eintrage in der genannten minde- 
stens einen anderen Spalte gruppiert. 5 

11. Relationales Datenbanksystem (200) mit einer An- 
zahl an Clients (210) und einer Suchmaschine 
(240) mit Modulen zum Parsen (310), Optimieren 
(330) und Ausfuhren (350) einer Anfrage (420, 450) 10 
von einem der Clients, die eine Pivotisierungsope- 
ration enthalt, die angibt: 

eine relationale Eingangstabelle (410) mit Zei- 
len und Spalten von Datenwerten und mit Spal- 15 
tennamen, die getrennt von den Datenwerten 
in den Spalten gespeichert sind, 
einen Namen einer Pivot-Spalte (411) in der 
Eingangstabelle, und 

einen Namen einer Wertspalte (412) in der Ein- 20 
gangstabelle, 

dadurch gekennzeichnet, daB die Suchma- 
schine Datenwerte in der Wertspalte urn die Pivot- 
Spalte transponiert, wobei sie mindestens einige 25 
der Datenwerte in getrennt gespeicherte und for- 
matierte Spaltennamen umwandelt, so daB sie eine 
pivotisierte Ausgangstabelle direkt aus der Ein- 
gangstabelle aufbaut, ohne eine der beiden Tabel- 
len in ein anderes oder aus einem anderen Format 30 
zu konvertieren. 

12. System nach Anspruch 11, wobei die Pivotisie- 
rungsoperation auBerdem eine Pivot-Liste (522) 
von Datenwerten in der Pivot-Spalte angibt, 35 

dadurch gekennzeichnet, daB die Daten- 
werte in der Pivot-Spalte aufgrund der Dateneintra- 
ge in der Pivot-Liste transponiert werden. 

13. System nach Anspruch 12, wobei die Eingangsta- 40 
belle andere Spalten (413) als die Pivot- und die 
Wertspalte aufweist, 

dadurch gekennzeichnet, daB die Suchma- 
schine Zeilen der Ausgangstabelle im Hinblick auf 
gleiche Werte der Datenwert-Eintrage in den ande- 45 
ren Spalten gruppiert (550). 

14. System nach Anspruch 12, wobei eine Anfrage 
(440, 460) von einem der Clients eine Entpivotisie- 
rungsoperation umfaBt, die angibt: 50 

eine pivotisierte relationale Eingangstabelle 
(430) mit Zeilen und Spalten von Datenwerten 
und mit Spaltennamen, die getrennt von den 
Datenwerten in den Spalten gespeichert sind, 55 
einen Namen (411) fur eine Wertspalte, 
einen Namen (412) fur eine Pivot-Spalte, und 
eine Pivot-Liste mit Namen von mindestens ei- 



nigen der Spalten (431 bis 434) in der pivoti- 
sierten Eingangstabelle, 

dadurch gekennzeichnet, daB die Suchma- 
schine die Spaltennamen in der Pivot-Liste urn die 
Pivot-Spalte transponiert (600), wobei sie diese 
Spaltennamen in getrennt gespeicherte und forma- 
tierte Datenwerte umwandelt, so daB sie eine un- 
pivotisierte Ausgangstabelle direkt aus der Ein- 
gangstabelle aufbaut, ohne eine von beiden Tabel- 
len in ein anderes oder aus einem anderen Format 
zu konvertieren. 

15. Relationales Datenbanksystem (200) mit einer An- 
zahl an Clients (210) und einer Suchmaschine 
(240) mit Modulen zum Parsen (310), Optimieren 
(330) und Ausfuhren (350) einer Anfrage (440, 460) 
von einem der Clients, die eine Entpivotisierungs- 
operation enthalt, die angibt: 

eine relationale Eingangstabelle (430) mit Zei- 
len und Spalten von Datenwerten und mit Spal- 
tennamen, die getrennt von den Datenwerten 
in den Spalten gespeichert sind, 
einen Namen fur eine Pivot-Spalte (412), und 
eine Pivot-Liste mit Namen von mindestens ei- 
nigen der Spalten (431 bis 434) in der Ein- 
gangstabelle, 

dadurch gekennzeichnet, daB die Suchma- 
schine die Spaltennamen in der Pivot-Liste urn die 
Pivot-Spalte transponiert (600), wobei sie diese Na- 
men in getrennt gespeicherte und formatierte Da- 
tenwerte umwandelt, so daB sie eine pivotisierte 
Ausgangstabelle direkt aus der Eingangstabelle 
aufbaut, ohne eine von beiden Tabellen in ein an- 
deres oder aus einem anderen Format zu konver- 
tieren. 

16. System nach Anspruch 15, wobei die Eingangsta- 
belle andere Spalten (435) als die Pivot- und die 
Wertspalte aufweist, 

dadurch gekennzeichnet, daB die Suchma- 
schine Zeilen der Ausgangstabelle im Hinblick auf 
gleiche Werte der Datenwert-Eintrage in den ande- 
ren Spalten gruppiert. 

17. Medium (133) mit Darstellungen von Anweisungen, 
urn einen geeignet programmierten Computer zu 
veranlassen, ein Verfahren (500) zum Transformie- 
ren von Daten aus einer unpivotisierten Eingangs- 
tabelle (410) einer relationalen Datenbank in eine 
pivotisierte Ausgangstabelle (430) auszufuhren, 

dadurch gekennzeichnet, daB alle folgen- 
den Schritte vollstandig innerhalb eines relationa- 
len Datenbankmanagementsystems (200) ausge- 
fuhrt werden, urn Tabellen zu verarbeiten, die Zeilen 
und Spalten von Eintragen mit Datenwert-Eintra- 
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gen sowie Eintrage mit Spaltennamen, die getrennt 
von den und in einem anderen Format als die Da- 
tenwert-Eintrage gespeichert werden, aufweisen, 
ohne daB eine Konvertierung in ein anderes oder 
aus einem anderen Gesamttabellenformat stattfin- 5 
det, mit den folgenden Schritten: 

Auswahlen (521) des getrennt gespeicherten 
Namens einer ersten der Spalten der Ein- 
gangstabelle als Pivot-Spalte, 10 
Auswahlen (523) des getrennt gespeicherten 
Namens einer zweiten der Spalten der Ein- 
gangstabelle als Wertspalte, 
Umwandeln (531) eines Satzes an Eintragen, 
die als Datenwerte in der Wertspalte gespei- 15 
chert sind, direkt in Eintrage, die als Spalten- 
namen-Eintrage in der Ausgangstabelle, ge- 
speichert sind, die pivotisierte Spalten in der 
Ausgangstabelle benennen, 
Anordnen (540) von Eintragen, die als Daten- 20 
werte in der Pivot-Spalte gespeichert sind, in 
entsprechende Datenwert-Eintrage in entspre- 
chend unterschiedlichen der pivotisierten Spal- 
ten der Ausgangstabelle, und 
Speichern (560) der Ausgangstabelle direkt in 25 
dem Datenbankmanagementsystem, ohne sie 
in ein anderes oder aus einem anderen Format 
zu konvertieren. 

18. Medium nach Anspruch 17 mit Darstellungen von 30 
Anweisungen, urn einen geeignet programmierten 
Computer zu veranlassen, ein Verfahren zum 
Transponieren von Daten aus einer pivotisierten 
Eingangstabelle einer relationalen Datenbank in ei- 
ne unpivotisierte Ausgangstabelle in der gleichen 35 
relationalen Datenbank zu transformieren, 

dadurch gekennzeichnet, daB alle folgen- 
den Schritte vollstandig innerhalb eines relationa- 
len Datenbankmanagementsystems ausgefuhrt 
werden, urn Tabellen zu verarbeiten, die Zeilen und 40 
Spalten von Eintragen mit Datenwerten sowie Da- 
tenwerte mit Spaltennamen, die getrennt von den 
und in einem anderen Format als die Datenwertein- 
trage gespeichert sind, aufweisen, ohne daB eine 
Umwandlung in ein anderes oder aus einem ande- 45 
ren Gesamttabellenformat stattfindet, wobei die 
Schritte aufweisen: 

Auswahlen des getrennt gespeicherten Na- 
mens einer ersten der Spalten der Eingangsta- 50 
belle als Pivot-Spalte, 

Auswahlen einer Vielzahl der getrennt gespei- 
cherten Namen der Spalten der Eingangstabel- 
le als Pivot-Liste, 

in der Ausgangstabelle Erzeugen einer Pivot- 55 
Spalte mit einem ausgewahlten Namen, der in 
einem Spaltennamen-Eintrag gespeichert ist, 
und einer Vielzahl getrennt gespeicherten Da- 



tenwert-Eintrage, 

Umwandeln der Spaltennamen-Eintrage in der 
Pivot-Liste in Datenwert-Eintrage in der Pivot- 
Spalte, 

in der Ausgangstabelle Erzeugen einer Wert- 
spalte mit einem ausgewahlten Namen, der in 
einem Spaltennamen-Eintrag gespeichert ist 
und einer Vielzahl separat gespeicherter Da- 
tenwert-Eintrage, 

Anordnen von Eintragen, die als Spaltenna- 
men-Eintrage in der Pivot-Liste gespeichert 
sind, in entsprechende Datenwert-Eintrage in 
entsprechend unterschiedlichen der Wertspal- 
te der Ausgangstabelle, und 
Speichern der Ausgangstabelle direkt in dem 
Datenbankmanagementsystem, ohne sie in ein 
anderes oder aus einem anderen Format urn- 
zuwandeln. 

19. Medium (133) mit Darstellungen von Anweisungen, 
urn einen geeignet programmierten Computer zu 
veranlassen, ein Verfahren (600) zum Transformie- 
ren von Daten aus einer pivotisierten Eingangsta- 
belle (430) einer relationalen Datenbank in eine un- 
pivotisierte Ausgangstabelle (410) umzuwandeln, 

dadurch gekennzeichnet, daB alle folgen- 
den Schritte vollstandig innerhalb eines relationa- 
len Datenbank-managementsystems (200) ausge- 
fuhrt werden, urn Tabellen zu verarbeiten, die Zeilen 
und Spalten von Eintragen mit Datenwerten sowie 
Eintrage mit Spaltennamen, die getrennt von den 
und in einem anderen Format als die Datenwert- 
Eintrage gespeichert sind, aufweisen, ohne daB ei- 
ne Umwandlung in ein anderes oder aus einem an- 
deren Tabellenformat stattfindet, mit den folgenden 
Schritten: 

Auswahlen (623) des getrennt gespeicherten 
Namens einer ersten der Spalten der Ein- 
gangstabelle als Pivot-Spalte, 
Auswahlen (621) einer Vielzahl der getrennt 
gespeicherten Namen der Spalten der Ein- 
gangstabelle als Pivot-Liste, in der Ausgangs- 
tabelle Erzeugen (632) einer Wertspalte mit ei- 
nem ausgewahlten Namen, der in einem Spal- 
tennamen-Eintrag gespeichert ist, und einer 
Vielzahl getrenntgespeicherter Datenwert-Ein- 
trage, 

Anordnen (640) von Eintragen, die als Spalten- 
namen-Eintrage in der Pivot-Liste gespeichert 
sind, in entsprechende Datenwert-Eintrage in 
entsprechenden anderen der Wertspalte der 
Ausgangstabelle, und 

Speichern (660) der Ausgangstabelle direkt in 
dem Datenbankmanagementsystem, ohne sie 
in ein anderes oder aus einem anderen Format 
zu konvertieren. 
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Revendications 

1. Un procede (500), execute par un ordinateur, de 
transformation des donnees d'une table de bases 

de donnees relationnelles d'entree non pivotee 5 4. 
(410) en une table de sortie pivotee (430), 

caracterise en ce que toutes les etapes sui- 
vantes sont executees entierement a I'interieur d'un 
systeme de gestion de bases de donnees relation- 
nelles (200) permettant le traitement de tables con- 10 
tenant des lignes et des colonnes d'elements con- 5. 
tenant des elements de valeurs de donnees, et 
comportant des elements contenant des noms de 
colonnes stockes distinctement et dans un format 
different des elements de valeurs de donnees, sans 15 
conversion vers ou depuis un format de table gene- 6. 
rale different,, les etapes executees par I'ordinateur 
comprenant: 

la selection (521 ) du nom stocke distinctement 20 
d'une premiere des colonnes de la table d'en- 7. 
tree, en tant que colonne pivot; 
la selection (523) du nom stocke distinctement 
d'une deuxieme des colonnes de la table d'en- 
tree, en tant que colonne de valeurs; 25 
la conversion (531) d'un ensemble des ele- 
ments stockes en tant que valeurs de donnees 
dans la colonne pivot, directementen elements 
stockes en tantqu'elements de noms de colon- 
nes dans la table de sortie, indiquant les colon- 30 
nes pivotees dans la table de sortie; 
le placement (540) d'elements stockes en tant 
que valeurs de donnees dans la colonne pivot, 
en elements de valeurs de donnees respectifs, 
dans des colonnes correspondantes differen- 35 
tes des colonnes pivotees de la table de sortie; 
le stockage (560) de la table de sortie directe- 
ment dans le systeme de gestion de bases de 
donnees, sans sa conversion vers un format 
different ou depuis un format different. 40 

2. Le procede selon la revendication 1 , caracterise 
en ce que I'etape de placement comprend, pour 
chaque element de valeurs de donnees de la co- 
lonne des valeurs situee dans la meme ligne de la 45 
table d'entree, en tantqu'element particulierde I'en- 
semble d'elements de valeurs de donnees dans la 
colonne pivot, le placement de I'element particulier 

de valeurs de donnees dans une certaine des co- 
lonnes pivotees de la table de sortie pivotee, cette 50 
colonne pivotee portant un nom correspondant a 
I'element particulier precite de valeurs de donnees 
de la colonne pivot. 

3. Le procede selon la revendication 1 , caracterise 55 
par une autre etape de selection (522) de certains 
elements de I'ensemble d'elements de valeurs de 
donnees de la colonne pivot, en tant que liste pivot, 



et dans lequel I'etape de conversion convertit, en 
elements de noms de colonnes, uniquement ces 
elements de valeurs de donnees de la liste pivot. 

Le procede selon la revendication 3, caracterise 
en ce que I'etape de conversion ne convertit, dans 
la table d'entree, aucune ligne qui presente des ele- 
ments de valeurs de donnees NULLES dans la co- 
lonne pivot. 

Le procede selon la revendication 1, caracterise 
en ce que la table d'entree comporte au moins une 
colonne (413) autre que les colonnes pivot et de va- 
leurs. 

Le procede selon la revendication 5, caracterise 
par le groupage (532), par valeurs egales des ele- 
ments de valeurs de donnees, des lignes de la table 
de sortie dans au moins une autre colonne. 

Un procede (600) de transformation de donnees, 
execute par un ordinateur, a partir d'une table de 
bases de donnees relationnelles d'entree pivotee 
(430) en une table de sortie non pivotee (410), 

caracterise en ce que toutes les etapes sui- 
vantes sont executees entierement a I'interieur d'un 
systeme de gestion de bases de donnees relation- 
nelles (200), permettant le traitement de tables con- 
tenant des lignes et des colonnes d'elements con- 
tenant des valeurs de donnees, et comportant des 
elements contenant des noms de colonnes stockes 
distinctement et dans un format different des ele- 
ments de valeurs de donnees, sans conversion vers 
ou depuis un format de table generale different, les 
etapes executees par I'ordinateur comprenant: 

la selection (623) du nom stocke distinctement 
d'une premiere des colonnes de la table d'en- 
tree, en tant que colonne pivot; 
la selection (621 ) d'une pluralite des noms stoc- 
kes distinctement des colonnes de la table 
d'entree, en tant que liste pivot; 
la creation (632), dans la table de sortie, d'une 
colonne de valeurs contenant un nom selec- 
tionne stocke dans un element de noms de co- 
lonnes et une pluralite d'elements de valeurs 
de donnees stockes distinctement; 
le placement (640) d'elements stockes en tant 
qu'elements de noms de colonnes de la liste 
pivot, en elements de valeurs de donnees res- 
pectifs, dans des colonnes correspondantes 
differentes de la colonne de valeurs de la table 
de sortie; 

le stockage (660) de la table de sortie directe- 
ment dans le systeme de gestion de bases de 
donnees, sans sa conversion vers un format 
different. 
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ou depuis un format different. 

8. Un procede selon la revendication 7, caracterise 
en ce que I'etape de placement comprend, pour 
chaque element, de valeurs de donnees particulier 
de chaque colonne particuliere des colonnes de la 
table d'entree de la liste pivot, le placement de I'ele- 
ment des valeurs de donnees particulier dans I'ele- 
ment des valeurs de donnees de la colonne de va- 
leurs de la table de sortie non pivotee dans une li- 
gne qui contient egalement un element de valeurs 
de donnees dans la colonne pivot correspondant a 
la colonne particuliere de la table d'entree. 

9. Le procede selon la revendication 7, caracterise 
en ce que la table d'entree comporte au moins une 
colonne (435) autre que les colonnes de la liste pi- 
vot. 

10. Le procede selon la revendication 9, caracterise 
en ce que I'etape de groupage groupe, par valeurs 
egales des elements de valeurs de donnees, les li- 
gnes de la table de sortie dans au moins ladite autre 
colonne. 

11. Un systeme de bases de donnees relationnelles 
(200), contenant la liste d'un certain nombre de 
clients (21 0) et un moteur de recherche (240), com- 
prenantdes modules pour analyser (310), optimiser 
(330) et executer (350) une requete (420, 450), en 
provenance de I'un des clients, contenant une ope- 
ration pivotante specifiant: 

une table d'entree relationnelle (41 0) contenant 
des lignes et des colonnes de valeurs de don- 
nees et contenant des noms de colonnes stoc- 
kes distinctement des valeurs de donnees dans 
les colonnes, 

un nom d'une colonne pivot (41 1 ) dans la table 
d'entree, et 

un nom d'une colonne de valeurs (41 2) dans la 
table d'entree, 

caracterise en ce que le moteur de recher- 
che permute (500) des valeurs de donnees dans la 
colonne de valeurs autour de la colonne pivot, con- 
vertissant au moins quelques-unes des valeurs de 
donnees en noms de colonnes stockes et formates 
distinctement, de maniere a construire une table de 
sortie pivotee directement depuis la table d'entree, 
sans conversion de I'une des deux tables vers un 
format different ou depuis un format different. 

12. Le systeme selon la revendication 11, dans lequel 
I'operation pivotante specifie en outre une liste pivot 
(522) de valeurs de donnees dans la colonne pivot, 
caracterise en ce que les valeurs de donnees dans 
la colonne pivot sont permutees sur la base des ele- 



ments de donnees dans la liste pivot. 

13. Le systeme selon la revendication 12, dans lequel 
la table d'entree comprend des colonnes (413) 

5 autres que la colonnes pivot et la colonne de va- 

leurs, caracterise en ce que les moteurs de re- 
cherche (550) groupent, dans les autres colonnes, 
des lignes de la table de sortie en valeurs egales 
des elements de valeur de donnees. 

10 

14. Le systeme selon la revendication 12, dans lequel 
une requete (440, 460), en provenance de I'un des 
clients, contient une operation non pivotante speci- 
fiant: 

15 

une table d'entree relationnelle pivotee (430) 
contenant des lignes et des colonnes de va- 
leurs de donnees et comprenant des noms de 
colonnes stockes distinctement des valeurs de 

20 donnees dans les colonnes, 

un nom (411) pour une colonne de valeurs, 
un nom (412) pour une colonne pivot, et 
une liste pivot contenant des noms d'au moins 
quelques-unes des colonnes (431-434) de la 

25 table d'entree pivotee, 

caracterise en ce que le moteur de recher- 
che permute (600) les noms de colonnes dans la 
liste pivot autour de la colonne pivot, convertissant 
30 ces noms de colonnes en valeurs de donnees stoc- 
kees et formatees distinctement, de maniere a 
construire une table de sortie non pivotee directe- 
ment a partir de la table d'entree, sans conversion 
d'une des deux tables vers un format different ou 
35 depuis un format different. 

15. Un systeme de bases de donnees relationnelles 
(200) contenant la liste d'un certain nombre de 
clients (21 0) et un moteur de recherche (240) com- 

40 prenantdes modules pour analyser (310), optimiser 
(330) et executer (350) une requete (440, 460), en 
provenance de I'un des clients, contenant une ope- 
ration non pivotante specifiant: 

45 . une table d'entree relationnelle (430) contenant 
des lignes et des colonnes de valeurs de don- 
nees et contenant des noms de colonnes stoc- 
kes distinctement des valeurs de donnees dans 
les colonnes, 

50 . un nom pour une colonne pivot (412), et 

une liste pivot contenant des noms d'au moins 
certaines des colonnes (431 -434) dans la table 
d'entree, 

55 caracterise en ce que le moteur de recher- 

che permute (600) les noms de colonnes dans la 
liste pivot autour de la colonne pivot, convertissant 
ces noms en valeurs de donnees stockees et for- 
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matees distinctement, de maniere a construire une 
table de sortie pivotee directement a partir de la ta- 
ble d'entree, sans conversion d'une des deux tables 
vers un format different ou depuis un format diffe- 
rent. 

16. Le systeme selon la revendication 15, dans lequel 
la table d'entree comprend des colonnes (435) 
autres que la colonne pivot et la colonne de valeurs, 
caracterise en ce que les moteurs de recherche 
groupent, dans les autres colonnes, des lignes de 
la table de sortie en valeurs egales des elements 
de valeur de donnees. 

17. Un moyen (133) portant des representations des- 
tructions pour permettre a un ordinateur adequate- 
ment programme d'executer un procede (500) de 
transformation de donnees depuis une table de ba- 
ses de donnees relationnelles d'entree non pivotee 
(410) en une table de sortie pivotee (430), 

caracterise en ce que toutes les etapes sui- 
vantes sont executees entierement a I'interieur d'un 
systeme de gestion de bases de donnees relation- 
nelles (200) permettant le traitement de tables con- 
tenant des lignes et des colonnes d'elements con- 
tenant des elements de valeurs de donnees, et 
comportant des elements contenant des noms de 
colonnes stockes distinctement et dans un format 
different des elements de valeurs de donnees, sans 
conversion vers ou depuis un format de table gene- 
rale different, les etapes comprenant: 

la selection (521 ) du nom stocke distinctement 
d'une premiere des colonnes de la table d'en- 
tree, en tant que colonne pivot; 
la selection (523) du nom stocke distinctement 
d'une deuxieme des colonnes de la table d'en- 
tree, en tant que colonne de valeurs; 
la conversion (531) d'un ensemble des ele- 
ments stockes en tant que valeurs de donnees 
dans la colonne pivot directement en elements 
stockes en tantqu'elements de noms de colon- 
nes dans la table de sortie, indiquant les colon- 
nes pivotees dans la table de sortie; 
le placement (540) d'elements stockes comme 
valeurs de donnees dans la colonne pivot, en 
tant qu'elements de valeurs de donnees res- 
pectifs dans des colonnes correspondantes dif- 
ferentes des colonnes pivotees de la table de 
sortie; 

le stockage (560) de la table de sortie directe- 
ment dans le systeme de gestion de bases de 
donnees, sans sa conversion vers un format 
different ou depuis un format different. 

18. Le moyen selon la revendication 17, portant en 
outre des representations d'instructions pour per- 
mettre a un ordinateur adequatement programme 



d'executer un procede de transformation de don- 
nees d'une table de bases de donnees relationnel- 
les d'entree pivotee en une table de sortie non pi- 
votee dans le meme systeme de bases de donnees 
5 relationnelles, 

caracterise en ce que toutes les etapes sui- 
vantes sont executees entierement a I'interieur d'un 
systeme de gestion de bases de donnees relation- 
nelles permettant le traitement de tables contenant 
10 des lignes et des colonnes d'elements contenant 
des valeurs de donnees, et comportant des ele- 
ments contenant des noms de colonnes stockes 
distinctement et ayant un format different de celui 
des elements de valeurs de donnees, sans conver- 
ts sion vers ou depuis un format de table general dif- 
ferent t , les etapes comprenant: 

la selection du nom stocke distinctement d'une 
premiere des colonnes de la table d'entree, en 
20 tant que colonne pivot; 

la selection d'une pluralite de noms stockes dis- 
tinctement des colonnes de la table d'entree, 
en tant que liste pivot; 

la creation dans la table de sortie d'une colonne 
25 pivot contenant un nom selectionne stocke 

dans un element de noms de colonnes et une 
pluralite d'elements de valeurs de donnees 
stockes distinctement; 

la conversion des elements de noms de colon- 
ic nes dans la liste pivot en elements de valeurs 
de donnees dans la colonne pivot; 
la creation dans la table de sortie d'une colonne 
de valeurs contenant un nom selectionne stoc- 
ke dans un element de noms de colonnes et 
35 d'une pluralite d'elements de valeurs de don- 
nees stockes distinctement; 
le placement d'elements stockes en tant que 
valeurs de donnees dans la colonne pivot, en 
elements de valeurs de donnees respectifs, 
40 dans des colonnes correspondantes differen- 
tes des colonnes de la table de sortie 
le stockage de la table de sortie directement 
dans le systeme de gestion de bases de don- 
nees, sans sa conversion vers un format diffe- 
rs rent ou depuis un format different. 

19. Un moyen (133) portant des representations d'ins- 
tructions pour permettre a un ordinateur adequate- 
ment programme d'executer un procede (600) de 

50 transformation de donnees a partir d'une table de 
bases de donnees relationnelles d'entree pivotee 
(430) en une table de sortie non pivotee (410), 

caracterise en ce que toutes les etapes sui- 
vantes sont executees entierement a I'interieur d'un 

55 systeme de gestion de bases de donnees relation- 
nelles (200) permettant le traitement de tables con- 
tenant des lignes et des colonnes d'elements con- 
tenant des valeurs de donnees, et comportant des 
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elements contenant des noms de colonnes stockes 
distinctement et ayant un format different de celui 
des elements de valeurs de donnees,, sans conver- 
sion vers ou depuis un format de table generale dif- 
ferent,, les etapes comprenant 5 

la selection (623) du nom stocke distinctement 
d'une premiere des colonnes de la table d'en- 
tree, en tant que colonne pivot; 
laselection (621) d'une pluralite des noms stoc- 10 
kes distinctement des colonnes de la table 
d'entree, en tant que liste pivot;, 
la creation (632) dans la table de sortie d'une 
colonne de valeurs contenant un nom selec- 
tionne stocke dans un element de noms de co- 15 
lonnes et d'une pluralite d'elements de valeurs 
de donnees stockes distinctement; 
le placement (640) d'elements stockes en tant 
qu'elements de noms de colonnes dans la liste 
pivot sous la forme d'elements de valeurs de 20 
donnees respectifs dans des colonnes corres- 
pondantes differentes des colonnes de valeurs 
de la table de sortie; 

le stockage (660) de la table de sortie directe- 
ment dans le systeme de gestion de bases de 25 
donnees, sans sa conversion vers ou depuis un 
format different. 
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